Wake-on-LAN (WOL) is an Ethernet computer networking standard that allows a computer to be turned on or awakened by a network message.
The message is usually sent by a program executed on another computer on the same local area network. It is also possible to initiate the message from another network by using subnet directed broadcasts or a WOL gateway service. Equivalent terms include wake on WAN, remote wake-up, power on by LAN, power up by LAN, resume by LAN, resume on LAN and wake up on LAN. In case the computer being awakened is communicating via Wi-Fi, a supplementary standard called Wake on Wireless LAN (WoWLAN) also exists.
The WOL and WoWLAN standards are often supplemented by vendors to provide protocol-transparent on-demand services, for example in the Apple Bonjour wake-on-demand (Sleep Proxy) feature.
Ethernet connections, including home and work networks, wireless data networks and the internet itself, are based on packets of data sent between computers. Wake-on-LAN (“WOL”) is implemented using a specially designed packet called a “magic packet”, which is sent to the computer to be woken up. The magic packet contains the MAC address of the destination computer which is an identifying number built into each network interface card (“MC”) or other Ethernet device in a computer. The MAC address enables each computer to be uniquely recognized and addressed on a network. Powered-down or turned off computers capable of Wake-on-LAN will contain network devices able to “listen” to incoming packets in a low-power mode while the system is powered down. If a magic packet is received that is directed to the device's MAC address, the NIC signals the computer's power supply or motherboard to initiate system wake-up, in much the same way as operating the power on switch would do.
The magic packet is sent on the data link layer (layer 2 in the OSI model) and when sent, is broadcast to all attached devices on a given network, using the network. The IP-address (layer 3 in the OSI model) is not used for this activity.
It is a common misconception that because Wake-on-LAN is built upon broadcast technology it can only be used within the current network subnet. While this is generally the case, there are some exceptions, and Wake-on-LAN can operate across any network in practice, given appropriate configuration and hardware, including remote wake-up across the internet.
In order for Wake-on-LAN to work, parts of the network interface need to stay on. This consumes a small amount of standby power, which is much less than normal operating power. Disabling wake-on-LAN when not needed, can therefore very slightly reduce power consumption on computers that are switched off but remain plugged into an energised power socket.
Typically WOL is used in server environments by configuring the host operating system of the server to shut down or power down the computer after periods of idleness, and rely thereafter on WOL to wake up that server.
While wake-on-LAN has found success in server environments in that kind of role, with the advent of virtualization and cloud computing trends of the last 10 years, the wake-on-LAN technology has ceased to be relevant.
Specifically in multi-tenant cloud computing, where multiple independent and isolated applications are co-located on a single operating system, wake-on-LAN cannot be used to passivate a single tenant when that tenant becomes idle. This is because there are normally one or more other tenants sharing the same computer system which may not be idle. As a result, WOL has ceased to be used in such environments.
Separately, in the era of multi-tenant cloud computing, such as PaaS, SaaS, and devops/dev-test environments, it is very common for half, or more, of all tenants (applications) within a multi-tenant server to be idle at any given moment. In conventional multi-tenant computing environments, idle tenants or applications are not treated in any different manner to busy or active tenants or applications, so that the idle applications or tenants continue to occupy the same physical memory reservation and CPU reservation that the application or tenant would/does occupy when it is active or busy.
Idle tenants or applications in these multi-tenant cloud computing environments thus represent wasted computational capacity (such as wasted CPU reservations, wasted memory capacity, wasted I/O bandwidth, etc), because any computational capacity reserved for idle tenants/applications is by definition not available for use by other active tenants/applications.
The Genesis of the present invention is a desire to provide an efficient scheme to redirect some or all of the reserved computational capacity of the idle tenants or applications to additional active/busy applications or tenants without shutting down or effecting the service level agreement (SLA) of the now-idle tenants/applications. This idle computational capacity could therefore potentially be more profitably redirected to other active or busy tenants or applications, thereby reducing the overall quantity of computing capacity required by shared computer system(s) to operate plural tenants.